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Abstract 


This memo discusses benefits and issues that arise when allowing 
Real-time Transport Protocol (RTCP) packets to be transmitted with 
reduced size. The size can be reduced if the rules on how to create 
compound packets outlined in RFC 3550 are removed or changed. Based 
on that analysis, this memo defines certain changes to the rules to 
allow feedback messages to be sent as Reduced-Size RTCP packets under 
certain conditions when using the RTP/AVPF (Real-time Transport 
Protocol / Audio-Visual Profile with Feedback) profile (RFC 4585). 
This document updates RFC 3550, RFC 3711, and RFC 4585. 


Table of Contents 


N 


«000-1001 


Introduction soya So FG Wes RU SR ESI Ue RU EAT it ele v e 3 
j-SsubüreMbolop APP" ——ÓTrP— 3 
Use Cases and Design Rationale ................. cele 4 
S.l. RICP Compound Packets. (Background) 4.221232 lel y US 4 
3.2. Use Cases for Reduced-Size RTOP ................ eere 6 
3.3. Benefits of Reduced-Size RTCP 2x ..-(weewen M eres ieee mer cete 7 
34. Issues with Reduced-Size RICP 44e. venei. vere ES 8 
34. T Middle. BOX SS. ueste esse RU ede x erE eg s Uv M RUE RV Rus 9 
3.4.2. Packet ValidatlOh iw eR eee e eee Se igi s SUR SSS 9 
3:423 .-Encryption/AutheéntICcatlOn «ced wid wig tise bie eee A eed eS 10 
3.4.4. RTP and RTCP Multiplex on the Same Port ............ 10 
324.5. Header Compression- ws reseni nng eau see ee ere Sees eg ve 11 
Use of Reduced-Size RTCP with AVBE .....9 09.3 0 3 er er os 11 
Aid. Definition of Redueed-Size RTOP ..&.c-.o.lg eee eh eR al wed 12 
472. Algorithm Considerations 4-04 peu Wt NT Re I he I ARE NUTS 12 
4L2.l. Verifrcation-of Delrvery 4.222.554 e sb ae SS AS 12 
4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP ..... 13 
4.2.3. Enforcing: Compound RTCP jac. 909 PI.) )3 7g I Ss 13 
4.2.4. Immediate Feedback Mode ................. celere 14 
S3xgtaTEngask ss aues e a Rus AA es teen SE Mi oc e P b Eo dd M MAE. dese 14 
Security Considerations- ss ss ese UE aes ee eus ene iE LOE equi eoe E UE Gee 14 
TANA Considerations ew 9 eec kA UENIRE RUE E RUE ND UR EUN RUE dr mE Ie eae 14 
AoOknowledgementsS? JS eu eee Chk ee He etse seva eis quu 15 
References ul tate ele x iine RUNDE EUR UNAM Sua els EUER S NL S aie a e ovate T5 
9L. Normative: References - vie gee sd vel ars cee e uere sme x ea Ss re 15 
92s Informative Referentes 1.1999 Rom Re Bee e P RURUS Lom Ee EUR E 16 


Johansson & Westerlund Standards Track [Page 2] 


RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 


Iz 


Introduction 


In RIP [RFC3550] it is currently mandatory to send RTP Control 
Protocol (RTCP) packets as compound packets containing at least a 
sender report (SR) or receiver report (RR), followed by a source 
description (SDES) packet containing at least the CNAME item. There 
are good reasons for this, as discussed below (see Section 3.1); 
however, it does result in the minimal RTCP packets being quite 
large. 


The RTP/AVPF profile [RFC4585] specifies new RTCP packet types for 
feedback messages. Some of these feedback messages would benefit 
from being transmitted with minimal delay.  AVPF provides some 
mechanisms to support this; however, for environments with low- 
bitrate links, these messages can still consume a large amount of 
resources and can introduce extra delay in the time it takes to 
completely send the compound packet in the network. It is therefore 
desirable to send just the feedback, without the other parts of a 
compound RTCP packet. This memo proposes such a mechanism for this 
and other use cases, as discussed in Section 3.2. 


There are a number of benefits with Reduced-Size RTCP; these are 
discussed in Section 3.3. 


The use of Reduced-Size RTCP is not without issues. This is 
discussed in Section 3.4. These issues need to be considered and are 
part of the motivation for this document. 


Finally, this document defines how AVPF is updated to allow for the 
transmission of Reduced-Size RTCP in a way that would not 
substantially affect the mechanisms that compound packets provide; 
see Section 4 for more details. The connection to AVPF (or SAVPF 
[RFC5124]) is motivated by the fact that Reduced-Size RTCP is mainly 
beneficial for event-driven feedback purposes and that the AVPF Early 
RTCP and Immediate Feedback modes make this possible. 


This document updates [RFC3550], [RFC3711], and [RFC4585]. 
Terminology 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


The naming convention for RTCP is often confusing. Below is a list 
of RTCP terms and what they mean. See also Section 6.1 in [RFC3550] 
and Section 3.1 in [RFC4585] for details. 
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RTCP packet: Can be of different types, contains a fixed header part 
followed by structured elements depending on RTCP packet type. 


Lower layer datagram: Can be interpreted as the UDP payload. It may 
however, depending on the transport, be a TCP or Datagram 
Congestion Control Protocol (DCCP) payload or something else. 
Synonymous to the "underlying protocol" defined in Section 3 in 
[RFC3550]. 


Compound RTCP packet: A collection of two or more RTCP packets. A 
compound RTCP packet is transmitted in a lower-layer datagram. It 
must contain at least an RTCP RR or SR packet and an SDES packet 
with the CNAME item. Often "compound" is left out, the 
interpretation of RTCP packet is therefore dependent on the 
context. 


Minimal compound RTCP packet: A compound RTCP packet that contains 
the RTCP RR or SR packet and the SDES packet with the CNAME item 
with a specified ordering. 


(Full) compound RTCP packet: A compound RTCP packet that conforms to 
the requirements on minimal compound RTCP packets and contains 
more RTCP packets. 


Reduced-Size RTCP packet: May contain one or more RTCP packets but 
does not follow the compound RTCP rules defined in Section 6.1 in 
[RFC3550] and is thus neither a minimal nor a full compound RTCP. 
See Section 4.1 for a full definition. 


3. Use Cases and Design Rationale 
3.1. RTCP Compound Packets (Background) 


Section 6.1 in [RFC3550] specifies that an RTCP packet must be sent 
as a compound RTCP packet consisting of at least two individual RTCP 
packets, first a sender report (SR) or receiver report (RR), followed 
by additional packets including a mandatory SDES packet containing a 
CNAME item for the transmitting source identifier. Below is a short 
description of what these RTCP packet types are used for. 


1. The sender and receiver reports (see Section 6.4 of [RFC3550]) 
provide the RTP session participant with the synchronization 
source (SSRC) identifier of all RTP session participants. Having 
all participants send these packets periodically allows everyone 
to determine the current number of participants. This 
information is used in the transmission scheduling algorithm. 
Thus, this is particularly important for new participants so that 
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they can quickly establish a good estimate of the group size. 
Failure to do this would result in RTCP senders consuming too 
much bandwidth. 


2. Before a new session participant has sent any RTP or RTCP packet, 
it can also avoid SSRC collisions with all the SSRCs it sees 
prior to that transmission. So the possibility to see a 
substantial proportion of the participating sources minimizes the 
risk of any collision when selecting SSRC. 


3. The sender and receiver reports contain some basic statistics 
usable for monitoring of the transport and thus enable 
adaptation. These reports become more useful if sent regularly, 
as the receiver of a report can perform analyses to find trends 
between the individual reports. When used for media transmission 
adaptation, the information becomes more useful the more 
frequently it is received, at least until one report per round- 
trip time (RTT) is achieved. Therefore, there is, in most cases, 
no reason not to include the sender or receiver report in all 
RTCP packets. 


4. The CNAME SDES item (see Section 6.5.1 of [RFC3550]) exists to 
allow receivers to determine which media flows should be 
synchronized with each other, both within an RTP session and 
between different RTP sessions carrying different media types. 
Thus, it is important to quickly receive this for each media 
sender in the session when joining an RTP session. 


5. Sender reports (SR) are used in combination with the above SDES 
CNAME mechanism to synchronize multiple RTP streams, such as 
audio and video. After having determined which media streams 
should be synchronized using the CNAME field, the receiver uses 
the sender report's NTP and RTP timestamp fields to establish 
synchronization. 


6. The CNAME SDES item also allows a session participant to detect 
SSRC collisions and separate them from routing loops. The 32- 
bit, randomly selected SSRC has some probability of collision. 
The CNAME is used as the longer canonical identifier of a 
particular endpoint instance that is bound to an SSRC. If that 
binding isn't received and kept current, the receiver may not 
detect an SSRC collision, i.e., two different CNAMEs using the 
same SSRC. It also can't detect an RTP-level routing loop, with 
the result that the same SSRC and CNAME arrive from multiple 
lower-layer source addresses. 
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Reviewing the above, it is obvious that both SR/RR and the CNAME are 
very important in order for new session participants to be able to 
utilize any received media and to avoid flooding the network with 
RTCP reports. In addition, the dynamic nature of the information 
provided would make it less useful if not sent regularly. 


The following sections will describe the cases when Reduced-Size RTCP 
is beneficial and will also show the possible issues that must be 


considered. 


3.2. Use Cases for Reduced-Size RTCP 


Below are listed a few use cases for Reduced-Size RTCP. 


Control Plane Signaling: The Open Mobile Alliance (OMA) Push-to-talk 
over Cellular (PoC) [OMA-PoC] makes use of Reduced-Size RTCP when 
transmitting certain events. The OMA PoC service is primarily 
used over cellular links capable of IP transport, such as the 
Global System for Mobile Connections (GSM) General Packet Radio 
Service (GPRS). 


Codec Control Signaling: An example that can be used with Reduced- 
Size RTCP is, e.g., Temporary Maximum Media Stream Bitrate Request 
(TMMBR) messages as specified in [RFC5104], which signal a request 
for a change in codec bitrate. These messages benefit from the 
usage of Reduced-Size RTCP in bad channel conditions, as Reduced- 
Size RTCP are much more likely to be successfully transmitted than 
larger compound RTCP. This is critical, as these messages are 
likely to occur when channel conditions are poor. Other examples 
of codec control usage for Reduced-Size RTCP are found in 
[MTSI-3GPP]. 


Feedback: An example of a feedback scenario that would benefit from 
Reduced-Size RTCP is Video streams with generic NACK. In cases 
where the RTT is shorter than the receiver buffer depth, generic 
NACK can be used to request retransmission of missing packets, 
thus improving playout quality considerably. If the generic NACK 
packets are transmitted as Reduced-Size RTCP, the bandwidth 
requirement for RTCP will be minimal, enabling more frequent 
feedback. As in the codec control case, it is important that 
these packets can be transmitted with as little delay as possible. 
Another interesting use for Reduced-Size RTCP is in cases when 
regular feedback is needed, as described in Section 3.3. 


Status Reports: One proposed idea is to transmit small measurement 
or status reports in Reduced-Size RTCP, and to split the minimal 
compound RTCP and transmit the individual RTCP separately. The 
status reports can be used either by the endpoints or by other 
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network monitoring boxes in the network. The benefit is that, 
with some radio access technologies, small packets are more robust 
to poor radio conditions than large packets. Additionally, with 
small (report) packets, there is a smaller risk that the report 
packets will affect the channel upon which they report. Another 
benefit is that it is possible, with Reduced-Size RTCP, to allow, 
for example, anonymous status reporting to be transmitted 
unencrypted. This is something that may be beneficial, for 
instance, for network monitoring purposes. 


3.3. Benefits of Reduced-Size RTCP 


As mentioned in the introduction, most advantages of using Reduced- 
Size RTCP packets exist in cases when the available RTCP bitrate is 
limited. This is because they can become substantially smaller than 
compound packets. A compound packet is forced to contain both an RR 
or an SR and the CNAME SDES item. The RR containing a report block 
for a single source is 32 bytes, an SR is 52 bytes. Both may be 
larger if they contain report blocks for multiple sources. The SDES 
packet containing a CNAME item will be 10 bytes plus the CNAME string 
length. Here, it is reasonable that the CNAME string is at least 10 
bytes to get a decent collision resistance. If the recommended form 
of user@host is used, then most strings will be longer than 20 
characters. Thus, a Reduced-Size RTCP can become at least 70-80 
bytes smaller than the compound packet. 


For low bitrate links, the benefits of this reduction in size are as 
follows: 


o For links where the packet-loss rate grows with the packet size, 
smaller packets are less likely to be dropped. Radio links are an 
example of such links. In the cellular world, there exist links 
that are optimized to handle RTP packets sized for carrying 
compressed speech. This increases the capacity and coverage for 
voice services in a given wireless network. Minimal compound RTCP 
packets are commonly 2-3 times the size of an RTP packet carrying 
compressed speech. If the speech packet over such a bearer has a 
packet-loss probability of p, then the RTCP packet will experience 
a loss probability of 1-(1-p)*x, where x is the number of 
fragments the compound packet will be split into on the link 
layer, i.e., commonly into 2 or 3 fragments. 


o There is a shorter serialization time, i.e., the time it takes the 
link to transmit the packet. For slower links, this time can be 
substantial. For example, transmitting 120 bytes over a link 
interface capable of 30 kbps takes 32 milliseconds (ms), assuming 
uniform transmission rate. 
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In cases when Reduced-Size RTCP carries important and time-sensitive 
feedback, both shorter serialization time and the lower loss 
probability are important to enable the best possible functionality. 
Having a packet-loss rate that is much higher for the feedback 
packets than the media packets hurts when trying to perform media 
adaptation to, for example, handle the changed performance present at 
the cell border in a cellular system. 


For high-bitrate applications, there is usually no problem to supply 
RTCP with sufficient bitrates. When using AVPF, one can use the 
"trr-int" parameter to restrict the regular reporting interval to 
approximately once per RTT or less often. As in most cases, there is 
little reason to provide regular reports of higher density than this; 
any additional bandwidth can then be used for feedback messages. The 
benefit of Reduced-Size RTCP in this case is limited, but exists. 

One typical example is video using generic NACK in cases where the 
RTT is low. Using Reduced-Size RTCP would reduce the total amount of 
bits used for RTCP. This is primarily applicable if the number of 
reports is large. This would also result in lower processing delay 
and less complexity for the feedback packets, as they do not need to 
query the RTCP database to construct the right messages. 


As message size is generally a smaller issue at higher bitrates, it 
is also possible to transmit multiple RTCP in each lower-layer 
datagram in these cases. The motivation behind Reduced-Size RTCP in 
this case is not size, rather it is to avoid the extra overhead 
caused by inclusion of the SR/RR and SDES CNAME items in each 
transmitted RTCP. 


Independently of the link type, there are additional benefits with 
sending feedback in small Reduced-Size RTCP. Applications that use 
RTCP AVPF in Early RTCP or Immediate Feedback mode need to send 
frequent event-driven feedback. Under these circumstances, the risk 
is reduced that the RTCP bandwidth becomes too high during periods of 
heavy feedback signaling. 


In cases when regular feedback is needed, such as the profile under 
development for TCP friendly rate control (TFRC) for RTP 
[TCP-FRIEND], the size of compound RTCPs can result in very high 


bandwidth requirements if the round-trip time is short. For this 
particular application, Reduced-Size RTCP gives a very substantial 
improvement. 


3.4. Issues with Reduced-Size RTCP 


This section describes the known issues with Reduced-Size RTCP and 
also provides a brief analysis of their effects and mitigation. 
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3.4.1. Middle Boxes 


Middle boxes in the network may discard RTCP that do not 
rules outlined in Section 6.1 of RFC 3550. Newer report 
interpreted as unknown by the middle box. For instance, 
payload type number is 207 instead of 200 or 201, it may 


April 2009 


follow the 
types may be 
if the 

be treated 


as unknown. The effect of this might, for instance, be that compound 


RTCP would get through while the Reduced-Size RTCP would 


be lost. 


Verification of the delivery of Reduced-Size RTCP is discussed in 


Section 4.2.1. 


3.4.2. Packet Validation 


A Reduced-Size RTCP packet will be discarded by the packet validation 
code in Appendix A of [RFC3550]. This has several impacts: 


Weakened Packet Validation: The packet validation code needs to be 


rewritten to accept Reduced-Size RTCP. In particular, 


this 


affects Section 9.1 in [RFC3550] in the sense that the header 
verification must take into account that the payload type numbers 
for the (first) RTCP in the lower-layer datagram may differ from 
200 or 201 (SR or RR). One potential effect of this change is 


much weaker validation that received packets actually 


are RTCP and 


not packets of some other type being wrongly delivered. Thus, 
some consideration should be given to ensure the best possible 
validation is available, for example, restricting Reduced-Size 
RTCP to contain only some specific RTCP packet types that are 


preferably signalled on a per-session basis. However, 


the 


application of a security mechanism for source authentication on 


the packets will provide much stronger protection. 


Old RTP Receivers: Any RTCP receiver without an updated packet 
validation code will discard the Reduced-Size RTCP, which means 
that the receiver will not see e.g., the contained feedback 
messages. The effect of this depends on the type of feedback 
message and the role of the receiver. For example, this may cause 
complete function loss in the case of attempting to send a 
Reduced-Size NACK message (see Section 6.2.1 of [RFC4585]) to a 
non-updated media sender in a session using the retransmission 
scheme defined by [RFC4588]. This type of discarding would also 
affect the feedback suppression defined in AVPF. The result would 


be a partitioning of the receivers within the session, 


with the 


old receivers only seeing the compound RTCP feedback messages and 


in Reduced- 


the newer ones seeing both. In this case, the old receivers may 
send feedback messages for events already reported on 
Size RTCP. 
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Bandwidth Considerations: The discarding of Reduced-Size RTCP would 
affect the RTCP transmission calculation in that the avg rtcp size 
value would become larger than for RTP receivers that exclude the 
Reduced-Size RTCP in this calculation (assuming that Reduced-Size 
RTCP are smaller than compound ones). Therefore, these senders 
would under-utilize the available bitrate and send with a longer 
interval than updated receivers. For most sessions, this should 
not be an issue. However, for sessions with a large portion of 
Reduced-Size RTCP, the updated receivers may time out non-updated 
senders prematurely. This is, however, not likely to occur, as 
the time between compound RTCP transmissions needs to become 5 
times that used by the Reduced-Size RTCP senders for it to happen. 


Computation of avg rtcp size: Long intervals between compound RTCP 
with many Reduced-Size RTCP in between may lead to a computation 
of a value for avg rtcp size that varies greatly over time. 
Investigation shows that although it varies, this is not enough of 
a problem to warrant further changes or complexities to the RTCP 
scheduling algorithm. 


3.4.3.  Encryption/Authentication 


The Secure Real-time Transport Protocol (SRTP) presents a problem for 
Reduced-Size RTCP. Section 3.4 of [RFC3711] states, "SRTCP MUST be 
given packets according to that requirement in the sense that the 
first part MUST be a sender report or a receiver report". 


Upon examination of how SRTP processes packets, it becomes obvious 
that SRTP has no real dependency on whether the first packet is an SR 
or an RR packet. What is needed is the common RTCP packet header, 
which is present in all the packet types, with a source SSRC. The 
conclusion is therefore that it is possible to use Reduced-Size RTCP 
with SRTP. Nevertheless, as this implies a change to the rules in 
[RFC3711], changes in SRTP implementations MAY become necessary. 


3.4.4. RIP and RTCP Multiplex on the Same Port 


In applications in which multiplex RTP and RTCP are on the same port, 
as defined in [MULTI-RTP], care must be taken to ensure that de- 
multiplexing is done properly even though the RTCP packets are 
reduced size. The downside of Reduced-Size RTCP is that more values 
representing RTCP packets exist, reducing the available RTP payload 
type space. However, Section 4 in [MULTI-RTP] already requires the 
corresponding RTP payload type range not be used when performing this 
multiplexing. 
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33 


4. 


4.5. Header Compression 


Two issues are related to header compression. Possible changes are 
left for future work: 


o Payload type number identification: The Robust Header Compression 
(ROHC) algorithm [RFC3095] needs to create different compression 
contexts for RTP and RTCP for optimum performance. If RTP and 
RTCP are multiplexed on the same port, the classification may be 
based on payload type numbers. The classification algorithm must 
here acknowledge the fact that the payload type number for (the 
first) RTCP may differ from 200 or 201. 


o Compression of RTCP: No IETF-defined header compression method 
compress RTCP; however, if such methods are developed in the 
future, these methods must take Reduced-Size RTCP in account. 


Use of Reduced-Size RTCP with AVPF 


Based on the above analysis, it seems feasible to allow transmission 
of Reduced-Size RTCP under some restrictions: 


o First of all, it is important that compound RTCPs are transmitted 
at regular intervals to ensure that the mechanisms maintained by 
the compound packets, like feedback reporting, work. The tracking 
of session size and number of participants warrants mentioning 
again, as this ensures that the RTCP bandwidth remains bounded 
independent of the number of session participants. 


o Second, as the compound RTCP packets are also used to establish 
and maintain synchronization between media, any newly joining 
participant in a session would need to receive compound RTCP from 
the media sender(s). 


This implies that the regular transmission of compound RTCP MUST be 
maintained throughout an RTP session.  Reduced-Size RTCP SHOULD be 
restricted to be used as extra RTCP (e.g., feedback), sent in cases 
when a regular compound RTCP packet would not otherwise have been 
sent. 


The usage of Reduced-Size RTCP SHALL only be done in RTP sessions 
operating in AVPF [RFC4585] or SAVPF [RFC5124] Early RTCP or 
Immediate Feedback mode.  Reduced-Size RTCP SHALL NOT be sent until 
at least one compound RTCP has been sent. In Immediate Feedback 
mode, all feedback messages MAY be sent as Reduced-Size RTCP. In 
Early RTCP mode, a feedback message scheduled for transmission as an 
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Early RTCP, i.e., not a Regular RTCP, MAY be sent as Reduced-Size 
RTCP. All RTCP that are scheduled for transmission as Regular RTCP 
SHALL be sent as compound RTCP as indicated by AVPF [RFC4585]. 


Definition of Reduced-Size RTCP 
A Reduced-Size RTCP packet is an RTCP packet with the following 
properties that make it deviate from the compound RTCP packet 


definition given in Section 6.1 in [RFC3550]: 


o contains one or more RTCP packet (s) 


o allows any RTCP packet type; however, see Section 4.2.1 
o MUST NOT be used for Regular (scheduled) RTCP report purposes 


o MUST NOT be used with the RTP/AVP profile [RFC3551] or the 
RTP/SAVP profile [RFC3711] 


Algorithm Considerations 
1. Verification of Delivery 


If an application is to use Reduced-Size RTCP, it is important to 
verify that the Reduced-Size RTCP packets actually reach the session 
participants. As outlined above in Section 3.4.1 and Section 3.4.2, 
packets may be discarded along the path or in the endpoint. 


A few verification rules are RECOMMENDED to ensure robust RTCP 
transmission and reception and to solve the identified issues when 
Reduced-Size RTCP is used: 


o The endpoint issue can be solved by introducing signaling that 
informs if all session participants are capable of Reduced-Size 
RTCP. See Section 5. 


o The middle box issue is more difficult, and here one will be 
required to use heuristics to determine whether or not the 
Reduced-Size RTCP packets are delivered. The method used to 
detect successful delivery of Reduced-Size RTCP packets depends on 
the packet type. The RTCP packet types for which successful 
delivery can be detected are: 


* Sender reports (SR): Successful transmission of a sender report 
can be verified by inspection of the echoed timestamp in the 
received receiver report (RR). This can also be used as a 
method to verify if Reduced-Size RTCP can be used at all. 
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* Feedback RTCP packets: In many cases, the feedback messages 
sent using Reduced-Size RTCP will result in either explicit or 
implicit indications that they have been received. An example 
of this is the RTP retransmission [RFC4588] that results from a 
NACK message [RFC4585]. Another example is the Temporary 
Maximum Media Stream Bitrate Notification (TMMBN) message 
resulting from a Temporary Maximum Media Stream Bitrate Request 
(TMMBR) [RFC5104]. A third example is the presence of a 
decoder refresh point [RFC5104] in the video media stream 
resulting from the Full Intra Request that was sent. 


RTCP packet types for which it is not possible to detect 
successful delivery SHOULD NOT be transmitted as Reduced-Size RTCP 
packets unless they are transmitted in the same lower-layer 
datagram as another RTCP packet type for which successful delivery 
can be detected. 


o An algorithm to detect consistent failure of delivery of Reduced- 
Size RTCP MUST be used by any application using Reduced-Size RTCP. 
The details of this algorithm are application dependent and 
therefore outside the scope of this document. 


If the verification fails, it is strongly RECOMMENDED that only 
compound RTCP, according to the rules outlined in RFC 3550, is 
transmitted. 


4.2.2. Single vs Multiple RTCP in a Reduced-Size RTCP 


The result of the definition in Section 4.1 may be that the resulting 
size of Reduced-Size RTCP can become larger than a regularly 
Scheduled compound RTCP packet. For applications that use access 
types that are sensitive to packet size (see Paragraph 2 in 

Section 3.3), it is strongly RECOMMENDED that the use of Reduced-Size 
RTCP is limited to the transmission of a single RTCP packet in each 
lower-layer datagram. The method to determine the need for this is 
outside the scope of this document. 


In general, as the benefit with large Reduced-Size RTCP packets is 
very limited, it is strongly RECOMMENDED to transmit large Reduced- 
Size RTCP packets as compound RTCP packets instead. 

4.2.3. Enforcing Compound RTCP 
As discussed earlier, it is important that the transmission of 


compound RTCP occurs at regular intervals. However, this will occur 
as long as the RTCP senders follow the AVPF scheduling algorithm 
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defined in Section 3.5 of [RFC4585]. This follows as all Regular 
RTCP MUST be full compound RTCP. Note that there is also a 
requirement on sending Regular RTCP in Immediate Feedback mode. 


4.2.4. Immediate Feedback Mode 


Section 3.3 of [RFC4585] gives the option to use AVPF Immediate 
Feedback mode as long as the group size is below a certain limit. As 
transmissions using Reduced-Size RTCP may reduce the bandwidth 
demand, such transmissions also open up the possibility of a more 
liberal use of Immediate Feedback mode. 


5. Signaling 


This document defines the "a-rtcp-rsize" Session Description Protocol 
(SDP) [RFC4566] attribute to indicate if the session participant is 
capable of supporting Reduced-Size RTCP for applications that use SDP 
for configuration of RTP sessions. It is REQUIRED that a participant 
that proposes the use of Reduced-Size RTCP shall itself support the 
reception of Reduced-Size RTCP. 


An offering client that wishes to use Reduced-Size RTCP MUST include 
the attribute "a-rtcp-rsize" in the SDP offer. If "a-rtcp-rsize" is 
present in the offer SDP, the answerer that supports Reduced-Size 
RTCP and wishes to use it SHALL include the "a-rtcp-rsize" attribute 
in the answer. 


In declarative usage of SDP, such as the Real Time Streaming Protocol 
(RTSP) [RFC2326] and the Session Announcement Protocol (SAP) 
[RFC2974], the presence of the attribute indicates that the session 
participant MAY use Reduced-Size RTCP packets in its RTCP 
transmissions. 


6. Security Considerations 


The security considerations of RTP [RFC3550] and AVPF [RFC4585] will 
apply also to Reduced-Size RTCP. The reduction in validation 
strength for received packets on the RTCP port may result in a higher 
degree of acceptance of spurious data as real RTCP. This 
vulnerability can mostly be addressed by usage of any security 
mechanism that provides authentication; one such mechanism is SRTP 
[RECSW EL]: 


7. IANA Considerations 


Following the guidelines in [RFC4566], the IANA has registered a new 
SDP attribute: 


Johansson & Westerlund Standards Track [Page 14] 


RFC 5506 Reduced-Size RTCP in RTP Profile April 2009 
o Contact name, email address, and telephone number: Authors of RFC 
5506 
o Attribute-name: rtcp-rsize 
o Long-form attribute name: Reduced-Size RTCP 
o Type of attribute: media-level 
o Subject to charset: no 
This attribute defines the support for Reduced-Size RTCP, i.e., the 
possibility to transmit RTCP that does not conform to the rules for 


compound RTCP defined in RFC 3550. It is a property attribute, which 
does not take a value. 
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